Add workspace/textDocumentContent request (#3852) - #3855
Conversation
|
I tried to use it with vscode-java and realised we need to make quite a few changes to vscode-java to try this out. In order to use features from 3.18 there, we'll need to upgrade to vscode-languageclient v10, and in order to do that, we'll need to modernize many aspects of the project. I'll open some issues on that repo for the steps we need to take. |
datho7561
left a comment
datho7561
left a comment
There was a problem hiding this comment.
Confirmed this is working by trying it out in vscode-java.
Here's what I needed to do to get it to work on vscode-java:
- Update vscode-languageclient to 10.0.0 (10.1.0 wasn't working)
- Call
this.registerProposedFeatures();in theTracingLanguageServerclient (this is a workaround that 10.1.0 was supposed to fix, but the fix wasn't working properly for me) - Update tsconfig.base.json to target
es2020and use thenodenextmodule system - The above changes caused some compiler errors due to API changes so I addressed those
- Remove the jdt:// content provider
- Remove the code that changes jdt:// links to a command invocation (extension.ts#288)
Do you want me to make a branch with these changes? Do you want to try and do that?
Thanks for building this out! I'll try your branch and test it. |
datho7561
left a comment
datho7561
left a comment
There was a problem hiding this comment.
Tried in out in my branch and it was working properly. Also confirmed that it doesn't crash in vscode-java without my changes (it won't be used until the vscode-java knows to use it though).
2 participants
This adds support for the new workspace/textDocumentContent request from LSP 3.18. It answers the same way the old custom java/classFileContents request does, using the same content-fetching code, so editors can now get decompiled/virtual file content without needing extra custom glue code. The old java/classFileContents request still works exactly as before. Fixes #3852.